feat(payments): source payment providers from database, drop YAML config#186
Merged
Conversation
…fig (#182) Payment providers (Lightning node, on-chain wallet, Revolut) are now built from the per-company `payment_method_config` rows via `PaymentMethodFactory` at startup, instead of the YAML `[lightning]`/`[revolut]` settings. The DB is now the sole source of truth: - Remove `Settings.lightning`/`Settings.revolut`, the `LightningConfig` enum, and `Settings::get_node`/`get_onchain`/`get_revolut`. - Remove the one-time YAML->DB payment_method_config seed migration. - Startup fails with a clear error if no enabled Lightning/on-chain config exists for the default (first) company; providers are configured via the admin API from now on. - On-chain provider now honours the DB `min_confirmations`/`address_type`/ `account` fields (previously hardcoded to 1 / p2wkh / default account). - Route the Revolut/Stripe settlement listeners through the factory. - `SubscriptionHandler::new` now takes the Revolut service as a parameter. The runtime still resolves a single global provider set from the default company; true per-company provider routing remains future work.
The user API now sources payment providers exclusively from the payment_method_config table and fails to start without an enabled Lightning + on-chain config. Update the E2E harness accordingly: - Start the admin API first (it runs the schema migrations and needs no payment providers), then seed LND Lightning + OnChain payment_method_config rows pointing at the docker-compose LND node, then start the user API. - Drop the now-ignored `lightning:` section from .github/e2e/api-config.yaml.
Contributor
Author
|
Follow-up: fixed the E2E harness, which broke because the user API now requires DB-configured payment providers (no YAML fallback).
Also dropped the now-ignored |
The admin API connected to the database but never ran migrations (despite the "Connect database and migrate" comment) — it relied on the user API having migrated first. This lets the admin API bootstrap the schema on its own, which the E2E harness now depends on: it starts the admin API first to create the schema, seeds payment_method_config, then starts the user API.
Contributor
Author
|
✅ Ran the full E2E suite locally against the docker-compose stack: 123 passed, 0 failed. Sequence confirmed working:
One extra fix was needed: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #182.
Completes the
PaymentMethodFactoryintegration so payment providers come from the database instead of YAML, and removes the now-redundant YAML config entirely (per discussion, the DB is the single source of truth).What changed
bin/api.rs) — the Lightning node, on-chain provider and Revolut service are built from the per-companypayment_method_configrows viaPaymentMethodFactory(default/first company). Startup fails with a clear error if no company exists or no enabled Lightning/on-chain config is present.min_confirmations,address_typeandaccountfromOnChainProviderConfignow take effect (previously hardcoded to1/p2wkh/ default account in the oldSettings::get_onchain()).Settings.lightning/Settings.revolut, theLightningConfigenum,Settings::get_node/get_onchain/get_revolut, and the one-time YAML→DB seed migration.config.yamlupdated.SubscriptionHandler::newnow takes the Revolut service as a parameter (was derived fromsettings.get_revolut()); all call sites updated.Multi-company semantics
The runtime still resolves a single global provider set from the default (first) company. True per-company provider routing is left as documented future work — the data model already carries
company_idend to end, but the settlement handlers andSubscriptionHandlerresolve one provider set per process.There is no YAML→DB bootstrap anymore. A deployment must have seeded
payment_method_configrows before upgrading (anything that ran the previous seed migration already has them). New deployments configure providers viaPOST/PATCH /api/admin/v1/payment_method_configs; the API refuses to start without an enabled Lightning + on-chain config for the default company.Testing
lnvps_apilib test suite: 221 passed, 0 failed (3 ignored).lnvps_api/lnvps_api_common/lnvps_dbbuild clean (lib + tests), no new warnings/clippy lints.No API surface change.